This model based on data from the RTS GMLC model prepared as a time-series enhancment of the classic IEEE 118 bus Reliability Test System (Barrows et al, "The IEEE Reliability Test System: A Proposed 2019 Update", IEEE Transactions on Power Systems, 35, 1, January 2020).  The RTS GMLC model has been adapted for use by PSO to illustrate the multi-decision cycle logic and provide a starting point for the development of other models.

As of December 2020, RTS GMLC model is in progress and has not been finalized.  There are a number of data issues to be fixed and others to be made more realistic.  In this PSO version:
-------------------------------------------------------
PROBLEM:	Real-time (RT) loads for Area 1 are approximately 140 MW lower than day-ahead (DA) loads in all hours.  Also, RT loads show a significant dip at the peak of each day.  

RESOLUTION:	RT loads for Area 1 have been set equal to DA loads.  The original RT loads are still available in the data, but are not used.

JUSTIFICATION:	Because load forecasts are typically quite accurate (e.g., <3% MSE) and because forecast errors of wind and solar are typically much larger than load forecast errors.
-------------------------------------------------------
PROBLEM:	Gas CTs have significantly worse commitment constraints than oil-fired CTs.

RESOLUTION:	Exchanged commitment data for oil-fired and gas-fired CTs.

JUSTIFICATION:	Gas-fired CTs are more flexible than oil fired.  Also, there were more oil-fired units identified than gas fired, even though oil is typically used only as a backup fuel in dual-fuel units.  It appears oil and gas data was inadvertently flipped.
-------------------------------------------------------
PROBLEM:	Steam units have commitment constraints and costs that make it impossible to commit the generator in day ahead (DA) or that cannot be accurately managed in DA.

RESOLUTION:	"Week Ahead" cycle added to model.  Inflexible generators identified as "Stage1" commitment in this cycle.

JUSTIFICATION:	In real world, inflexible generators would be self-scheduled or committed by a process before DA.
-------------------------------------------------------
PROBLEM:	Insufficient flexibility to handle DA forecast errors in RT.  There is no data on how variability and uncertainty should be made from an operational perspective.  

RESOLUTION:	Added Hour-Ahead (HA) cycle to commit flexible CTs.  Added "Flex_RT" reserves to provide capacity in HA to manage variability an uncertainty in RT.

JUSTIFICATION:	In real world, flexible generation can be committed and decommitted close to real time.  The HA cycle takes advantage of the ability to commit and decommit flexible generation closer to RT, consistent with original data.  Also, flexibility is constantly deployed as RT approaches, either through deployment of ancillary services or, more commonly, by operator interventions and reliability processes. 
-------------------------------------------------------
PROBLEM:	Flexible "Peaker" units are modeled with inflexible data that makes standard PSO logic impractical.  Normally, peaker status can be relaxed DA allowing for more efficient solutions.  However, MinDispatch constraints mean that when CTs are committed in HA, they can only be committed at a minimum level.  Rather than violate power balance, units are not committed enough to meet reserve requirements.

RESOLUTION:	Enforced commitment constraints for all units in DA.

JUSTIFICATION:	n/a, though this is closer to standard practice
-------------------------------------------------------
PROBLEM:	All branches are enforced.  While this is not a problem for a small model, this is unrealistic for large systems, especially when contingencies need to be included.

RESOLUTION:	Added "system cycle" (SC) to quickly identify an approximate power flow and associated constraints that should be enforced, and those that can be monitored.  Applied logic to perform security analysis and use prior results to inform later decisions.

JUSTIFICATION:	Practical implementation on real systems requires selective enforcement of security constraints.  Without knowledge of what constraints are significant, another mechanism is needed to identify needed constraints.  Security analysis
-------------------------------------------------------
PROBLEM:	Too much "non-normalized" data.  Generators in the same class have mostly identical data.  

RESOLUTION:	Generators mapped to groups, and data restructured to use group mapping where appropriate.

JUSTIFICATION:	Managing large and complex data sets is difficult, and care is needed to organize data as transparently and simply as possible.
-------------------------------------------------------
PROBLEM: The Average Heat rate at minimum Power (Pmin) is misplaced as Incremental Heat rate (HCV_PNT). There is no Base heat for the Incremental heat rate curves (HCV_ATT)

RESOLUTION: removed the Average Heat rate at Pmin from the incremental heat rate curves and add Base heat for each Incremental Heat rate curve. 

JUSTIFICATION: Incremental Heat rate curves definition requires the Base heat of injector to calculate each generator's fuel dispatch correctly.
_______________________________________________________
OTHER NOTES:

How decisions should be made from an operational perspective is critical information to model the impact of uncertainty and variability. This is addressed in the PSO model by adding WA and HA cycles to commit generators that are less or more flexible than those that need to be committed DA.

The model solves July 10-16, 2020, consistent with results in the reference paper.  This includes two days (July 8 and 9) to establish initial conditions, and a look ahead that is as much as 6 days into the future (i.e., the last horizon of the WA cycle solves July 16-22).  

The RT cycle is solved on a rolling 15 minutes with no look-ahead.  There is only forecast data for DA and RT, and the RT forecasts are also applied to the HA cycle.  Thus, there is little difference between HA and RT cycles except for the finer time granularity (5 minutes vs 15 minutes).  This reduces the total number of solutions considerably and simplifies review of results.  Once a user is familiar with the current set up, it is recommended that the RT cycle be modified to solve on a rolling 5 minutes with or without look ahead to see how impacts of ramping or storage affect results.

Current model does not include

-- HVDC branch
-- management of storage constraints
-- forced outage rates
-- emissions
-- AC power-flow data

PSO can model these details, other than AC power flow.  They have not been included in the model because they appear to not have have not been used by NREL case studies.  However, other details not included in NREL case studies have been included since these are critical to RT operations.